Small note: can we ensure the TransactionContextID construction here matches the spec
H(TxType ∥ Account ∥ MPTokenIssuanceID ∥ SequenceOrTicket ∥ TxSpecific)
where:

• Send / ConvertBack: TxSpecific = Receiver ∥ CBSVersion
• Convert: TxSpecific = Account ∥ 0

The context hash is adapting to the rippled's implementation hash. We'll change on both sides if anything requires modification.

The current hashing is like:
We have a common hash matches TxType ∥ Account ∥ MPTokenIssuanceID ∥ SequenceOrTicket, see the function mpt_add_common_zkp_fields.

Convert: TxSpecific = amount. (see mpt_get_convert_context_hash). because we are trying to add all the inputs into the hash function. (account already included in the common hash)
ConvertBack : TxSpecific = amount | CBSVersion. (account already included in the common hash)
Send: TxSpecific = receiver | CBSVersion.
Clawback: TxSpecific = amount | holder

The difference with the doc:

• introduced for convert/convertback/clawback.
• some TxSpecific fields omit the Account field, since it is already included in the common hash section.

What we will add according to what you suggested in the doc:

• We need to pass in the ticket number if it is a ticket, although the interface won't change.
• We'll add version 0 for convert: TxSpecific = amount | 0

Please suggest if this looks good to you or any other modifications needed?

Thanks for the detailed breakdown! The common hash structure aligns well with the spec. From the spec side, I’d prefer that we keep the TransactionContextID definition. The cryptographic intent there is that TxSpecific binds the transaction context and state freshness (identity||version), rather than public payload inputs like the plaintext amount. For example, in ConfidentialMPTConvert, the spec intentionally defines TxSpecific := Account||0 to maintain a uniform semantic structure across transaction types, where 0 explicitly indicates that no CBSVersion is involved. The amount is already bound inside the Fiat–Shamir transcript (mG) during challenge computation, so it does not need to be part of TransactionContextID.

To keep the transcript definition consistent with the spec, my preference for the semantic shape of TxSpecific would be:

ConfidentialMPTSend: receiver||CBSVersion
ConfidentialMPTConvertBack: receiver (=Account)||CBSVersion
ConfidentialMPTConvert: account||0
ConfidentialMPTClawback: holder||0

The include of arpa/inet.h is not portable to Windows. While Windows is handled with the _WIN32 defines for byte order operations below, the header will fail to compile on Windows. Consider making this include conditional with #ifndef _WIN32 or using winsock2.h for Windows instead.

Hi @yinyiqian1 , can this issue be fixed? I had to create a patch on our end to handle Windows. Probably something like this should work:

#ifdef _WIN32
    #include <winsock2.h>
#else
    #include <arpa/inet.h>
#endif

Missing validation: The function does not validate that n_recipients is greater than zero. If n_recipients is 0, the code will access pk[0].data at lines 580 and 587, which is undefined behavior. Add a check to ensure n_recipients > 0 at the beginning of the function.

@yinyiqian1 Hi, Would it make sense to call this struct as mpt_confidential_participant or something else that does not imply that it is a recipient of the confidential amount? As other then the receiver all other are the participants of the send transaction?

@Patel-Raj11 Thank you. Yes, it makes sense. How about mpt_confidential_party, which is shorter, but similar to participant?

mpt_confidential_party sounds good to me.

I think if each participant/recipient has different blinding factor, the proof generation and verification both works. Since there is no BlindingFactor field for ConfidentialMPTSend transaction type, different blinding factor's can be used by each participant to encrypt the same amount.
Could you confirm this on your end once and if it's true then should we append multiple blinding factors here?

No. We should use the same blinding factor for encrypting the participant/recipient. The blinding factor is generated by the sender off-chain. It is a value that zkproof needs to verify, it should not be part of the request.
If we use different blinding factors for the ElGamal ciphertexts, the Equality Proof inside the ZK-Proof would fail.

We can use another set of blinding factor for pedersen commitment. But for the ElGamal ciphertexts, we must use the same blinding factor for issuer,auditor and sender.

Btw, in ConfidentialMPTConvert, it is a public amount, we can put the blinding factor in the request. We are not trying to prove the knowledge of the randomness in that case. We are proving the knowledge of private key in that case, using schnorr proof.

Key difference:

• convert: prove the knowledge of identity (private key)
• send (equality proof part): prove the knowledge of randomness (blinding factor) and the actual value we are encrypting.

If we use different blinding factors for the ElGamal ciphertexts, the Equality Proof inside the ZK-Proof would fail.

I have an integration test that runs on this commit and that test uses different blinding factors for sender, receiver and issuer. The proof that gets submitted to rippled still gets verified successfully. test_valid_multi_proof in mpt-crypto also verifies with different blinding factor. So wanted to know if something changed recently or it's some logic in rippled verification part that requires same blinding factor to be used for encryption for Send transaction?

@Patel-Raj11 Sorry for the confusion. We're going to have an optimization that is forcing the shared r. This was newly supported from the proof_same_plaintext_multi_shared_r.c. By that time, different blinding factor will fail.

Ok, sounds good. I'll change my implementation now to use same blinding factor, but there will be change in the utility functions to use secp256k1_mpt_prove_equality_shared_r right?

Yes. That is correct

But I'll update the Rippled's c++ code first, and then make the changes in this SDK lib.